Skip to content

Conversation

@dejanstrbac
Copy link
Contributor

Implementing changes requested

@dejanstrbac dejanstrbac changed the title Add CONDSTORE extension support imapserver: Add CONDSTORE extension support Jun 6, 2025
@emersion
Copy link
Owner

emersion commented Jun 9, 2025

Ref #687 which contained the previous version of this PR.

Copy link
Owner

@emersion emersion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM apart from these comments!

}
}

shouldSendModSeqStatus := c.enabled.Has(imap.CapIMAP4rev2) || c.server.options.caps().Has(imap.CapCondStore)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think IMAP4rev2 has CONDSTORE folded in? Is there a reason to send mod seq when it's enabled?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMAP4rev2 requires QRESYNC which on the other hand requires CONDSTORE. I added support in capability check for this chain

Comment on lines 164 to 165
msg.modSeq = mbox.highestModSeq
mbox.highestModSeq++
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we bump mbox.highestModSeq before setting the message's mod seq?

If we bump mbox.highestModSeq after, then it's not the highest mod seq, it's the next mod seq.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, fixed

return
}

if options.ChangedSince > 0 && msg.modSeq <= options.ChangedSince {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be msg.modSeq < options.ChangedSince? In other words, we want to send the message if CHANGEDSINCE equals MODSEQ.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The RFC specifies that the message's modSeq must be strictly greater than the CHANGEDSINCE value (we have the opposite condition)

var modifiedSeqNums []uint32
var modifiedMsgs []*message

mbox.mutex.Lock()
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: we can use mbox.forEach instead of manually locking/unlocking.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed, updated

Comment on lines 444 to 445
mbox.highestModSeq++
msg.modSeq = mbox.highestModSeq
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we handle the mod seq bump inside msg.store? This would make it so we don't forget bumping it if we call this function from elsewhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed, updated


for i, seqNum := range modifiedSeqNums {
msg := modifiedMsgs[i]
mbox.Mailbox.tracker.QueueMessageFlags(seqNum, msg.uid, msg.flagList(), mbox.tracker)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to move the QueueMessageFlags call outside of the mbox.forEach loop?

msg.flagList can only be called with the mailbox mutex locked. QueueMessageFlags never blocks.

}

if !flags.Silent && len(modifiedMsgs) > 0 {
for i, seqNum := range modifiedSeqNums {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of open-coding this, could we accumulate an imap.SeqSet of modified message sequence numbers in the loop above, and pass that to mbox.Fetch?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update the whole logic with an accumulator

@dejanstrbac dejanstrbac changed the title imapserver: Add CONDSTORE extension support imapserver: Add CONDSTORE and QRESYNC extension support Sep 21, 2025

if expunge {
w := &ExpungeWriter{}
w := &ExpungeWriter{conn: c}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@emersion this is an unrelated bug, conn was missing

Copy link
Owner

@emersion emersion Oct 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RFC 9051 section 6.4.1:

No untagged EXPUNGE responses are sent.

Maybe a comment would be warranted here.

@WhyNotHugo
Copy link

I notice that this branch produces:

UID FETCH 1:* (FLAGS) (CHANGEDSINCE 123) VANISHED

I believe the following to be correct:

UID FETCH 1:* (FLAGS) (CHANGEDSINCE 123 VANISHED)

From: https://datatracker.ietf.org/doc/html/rfc7162#section-3.2.6:

The VANISHED UID FETCH modifier MUST only be specified together with the CHANGEDSINCE UID FETCH modifier.

@WhyNotHugo
Copy link

WhyNotHugo commented Oct 23, 2025

There's also an example in that section of the RFC:

   C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345
       VANISHED)

@emersion
Copy link
Owner

emersion commented Oct 23, 2025

Could we try merging CONDSTORE first, then do QRESYNC as a second step? Both at the same time are a bit much to review, especially since commits aren't split into semantic chunks. (I'd suggest opening a new draft PR based on this one for QRESYNC, then dropping the QRESYNC stuff from this PR. I can help with that if needed.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants